Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification table (merge main and fix) #3

Merged
merged 435 commits into from
Mar 24, 2023

Conversation

wxiaoguang
Copy link

No description provided.

sillyguodong and others added 30 commits February 23, 2023 15:50
…#23088)

Fix: go-gitea#22990

---
Before, the return value of the api is always false,regrardless of
whether the entry of `sync_on_commit` is true or false.
I have confirmed that the value of `sync_on_commit` dropped into the
database is correct.
So, I think it is enough to make some small changes.
…gitea#23014)

As the title. Label/assignee share the same code.

* Close go-gitea#22607
* Close go-gitea#20727

Also:

* partially fix for go-gitea#21742, now the comment reaction and menu work with
keyboard.
* partially fix for go-gitea#17705, in most cases the comment won't be lost.
* partially fix for go-gitea#21539
* partially fix for go-gitea#20347
* partially fix for go-gitea#7329

### The `Enter` support

Before, if user presses Enter, the dropdown just disappears and nothing
happens or the window reloads.

After, Enter can be used to select/deselect labels, and press Esc to
hide the dropdown to update the labels (still no way to cancel ....
maybe you can do a Cmd+R or F5 to refresh the window to discard the
changes .....)


This is only a quick patch, the UX is still not perfect, but it's much
better than before.


### The `confirm` before reloading

And more fixes for the `reload` problem, the new behaviors:

* If nothing changes (just show/hide the dropdown), then the page won't
be reloaded.
* If there are draft comments, show a confirm dialog before reloading,
to avoid losing comments.

That's the best effect can be done at the moment, unless completely
refactor these dropdown related code.

Screenshot of the confirm dialog:

<details>


![image](https://user-images.githubusercontent.com/2114189/220538288-e2da8459-6a4e-43cb-8596-74057f8a03a2.png)

</details>

---------

Co-authored-by: Brecht Van Lommel <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
I found `FindAndCount` which can `Find` and `Count` in the same time
Maybe it is better to use it in `FindProjects`

---------

Co-authored-by: Lunny Xiao <[email protected]>
Fix go-gitea#23082.

This bug is caused by a nil context in
go-gitea#23082 (comment) .

---------

Co-authored-by: Lunny Xiao <[email protected]>
Currently, Gitea will run actions automatically which are triggered by
fork pull request. It's a security risk, people can create a PR and
modify the workflow yamls to execute a malicious script.

So we should require approval for first-time contributors, which is the
default strategy of a public repo on GitHub, see [Approving workflow
runs from public
forks](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).

Current strategy:

- don't need approval if it's not a fork PR;
- always need approval if the user is restricted;
- don't need approval if the user can write;
- don't need approval if the user has been approved before;
- otherwise, need approval.

https://user-images.githubusercontent.com/9418365/217207121-badf50a8-826c-4425-bef1-d82d1979bc81.mov

GitHub has an option for that, you can see that at
`/<owner>/<repo>/settings/actions`, and we can support that later.

<img width="835" alt="image"
src="https://user-images.githubusercontent.com/9418365/217199990-2967e68b-e693-4e59-8186-ab33a1314a16.png">

---------

Co-authored-by: Lunny Xiao <[email protected]>
Partially fix go-gitea#23050

After go-gitea#22294 merged, it always has a warning log like `cannot get
context cache` when starting up. This should not affect any real life
but it's annoying. This PR will fix the problem. That means when
starting up, getting the system settings will not try from the cache but
will read from the database directly.

---------

Co-authored-by: Lauris BH <[email protected]>
Right now on the PR 'File Change' Tab, the file title header sticky to
the top on large screens has wrong height, resulting in wrong ui
behavior when scrolling down. This PR is to fix this.

Before:

<img width="964" alt="截屏2023-02-24 17 12 29"
src="https://user-images.githubusercontent.com/17645053/221140409-025c4a84-6bbe-4b5b-a13f-bd2b79063522.png">

After:
<img width="1430" alt="截屏2023-02-24 21 10 12"
src="https://user-images.githubusercontent.com/17645053/221186750-0344d652-4610-4a90-a4c0-7f6269f950d6.png">
This notably brings support for GOARCH=loong64, among other fixes.

---------

Signed-off-by: WANG Xuerui <[email protected]>
Co-authored-by: zeripath <[email protected]>
The **Admin Repository Management** page and the **Explore Repository**
page both use the `RenderRepoSearch` function. In this function, the
`OnlyShowRelevant` search option is `true` when querying repositories
for admin page.


https://github.com/go-gitea/gitea/blob/edf98a2dc30956c8e04b778bb7f1ce55c14ba963/routers/web/explore/repo.go#L99-L115

Refer to
[go-gitea#19361](https://github.com/go-gitea/gitea/pull/19361/files#diff-8058dfb85557010e0592d586675ec62ce406af7068e6311f39c160deac37f149R497),
the repositories with `is_empty=true` will be hidden if
`OnlyShowRelevant` is `true`.

Administrators should be able to see all repositories. So
`OnlyShowRelevant` shouldn't be set to `true` .

---------

Co-authored-by: Andrew Thornton <[email protected]>
This PR does a bulk update of a lot of our go deps.

I have not included nektos/act and xorm for the following reasons:
* Xorm updates can sometimes be complex and I'd rather do that in a
separate PR
* I think people more update with the actions code should double check
that the latest nektos/act library works correctly.

---------

Signed-off-by: Andrew Thornton <[email protected]>
Co-authored-by: techknowlogick <[email protected]>
Previously only the last few activities where available. This works for
all activity and for activity on a date chosen on the heatmap.
Unfortunately xorm's `builder.Select(...).From(...)` does not escape the
table names. This is mostly not a problem but is a problem with the
`user` table.

This PR simply escapes the user table. No other uses of `From("user")`
where found in the codebase so I think this should be all that is
needed.

Fix go-gitea#23064

Signed-off-by: Andrew Thornton <[email protected]>
This includes pull requests that you approved, requested changes or
commented on. Currently such pull requests are not visible in any of the
filters on /pulls, while they may need further action like merging, or
prodding the author or reviewers.

Especially when working with a large team on a repository it's helpful
to get a full overview of pull requests that may need your attention,
without having to sift through the complete list.
There was a warning while building the docs: `Building sites … WARN
2023/02/25 08:56:37
"/workspace/gitea/docs/content/doc/secrets/overview.en-us.md:1:1":
duplicate menu entry with identifier "overview" in menu "sidebar"`.

### Before

![image](https://user-images.githubusercontent.com/20454870/221348741-55cef254-f2ac-4507-9a66-818b406c668f.png)

### After

![image](https://user-images.githubusercontent.com/20454870/221348757-42066303-e1b7-43fe-9c4f-e05182fbabdd.png)

Signed-off-by: Yarden Shoham <[email protected]>
…k events (go-gitea#23065)

Using `touchstart` for `click` events is a black magic for mobile
browsers (Google: `fastclick`).

However, it causes many UX problems if the fastclick is used without
careful design.

Fomantic UI uses this fastclick for its `dimmer` and `dropdown`, it
makes mobile users feel strange when they "touch" the dropdown menu.


This PR uses a simple patch to fix that behavior. Then the Fomantic
dropdown only uses `click` for click events.

This PR is simple enough and won't cause hidden bugs even if the patch
doesn't work. In the future, if there are more patches for Fomantic UI,
the patches could be placed in a directory like
`web_src/fomantic/patches/001-fix-click-touchstart`, etc.


![image](https://user-images.githubusercontent.com/2114189/220551915-bd28e8cc-507f-43c7-bb4a-b24f7ff3934d.png)

Co-authored-by: Lunny Xiao <[email protected]>
Allows using Minio with untrusted certificates

Closes go-gitea#23128

Signed-off-by: Yarden Shoham <[email protected]>
GetActiveStopwatch & HasUserStopwatch is a hot piece of code that is
repeatedly called and on examination of the cpu profile for TestGit it
represents 0.44 seconds of CPU time. This PR reduces this time to 80ms.

---------

Signed-off-by: Andrew Thornton <[email protected]>
Co-authored-by: KN4CK3R <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
Co-authored-by: delvh <[email protected]>
…me (go-gitea#23135)

Close  go-gitea#10468

Without SimpleMDE/EasyMDE, using Simple Textarea, the button text could
be changed when content changes.

After introducing SimpleMDE/EasyMDE, there is no code for updating the
button text.
silverwind and others added 26 commits March 21, 2023 17:38
- Set opaque background on markup images so they can visually break
`<hr>`
- Change padding of comment box so `padding` is provided by the
`.markup` element instead of its parent, matching the file rendering
view which does the same.

Before:
<img width="243" alt="Screenshot 2023-03-19 at 19 22 03"
src="https://user-images.githubusercontent.com/115237/226198663-8ff4d940-6a15-452d-ac58-14485b37fbc7.png">

After:
<img width="261" alt="Screenshot 2023-03-19 at 19 23 26"
src="https://user-images.githubusercontent.com/115237/226198689-1bf56561-4726-46dc-b583-423d65e1e13a.png">
<img width="263" alt="image"
src="https://user-images.githubusercontent.com/115237/226199002-e93c817d-6d9c-4b98-bad8-0aa0bd45b62f.png">

Example documents:

https://try.gitea.io/silverwind/symlink-test/src/branch/master/test-page.md
https://github.com/silverwind/symlink-test/blob/master/test-page.md
This updates the PR docs and explains how to work with PRs, for those
who may not know.

It was mentioned that this page could explain PRs a bit better, in case
some users are not familiar with GitHub or similar forges.

Signed-off-by: jolheiser <[email protected]>
…s. (go-gitea#23542)

This PR follows go-gitea#22599 and go-gitea#23450

The major improvements:

1. The `aria-*.js` are totally transparent now, no need to call
`attachDropdownAria` explicitly anymore.
* It hooks the `$.fn.checkbox` and `$.fn.dropdown`, then our patch
works.
* It makes all dynamically generated checkbox/dropdown work with a11y
without any change
* eg: the `conversation.find('.dropdown').dropdown();` in `repo-diff.js`
2. Since it's totally transparent now, it could be easier to modify or
remove in the future.
3. It handles all selection labels as well (by onLabelCreate), so it
supports "multiple selection dropdown" now.
* It partially completes one of my TODOs: `TODO: multiple selection is
not supported yet.`
4. The code structure is clearer, code blocks are splitted into
different functions.
* The old `attachOneDropdownAria` was splitted into separate functions.
* It makes it easier to add more fine tunes in the future, and co-work
with contributors.
6. The code logic is similar as before, only two new parts: 
    1. the `ariaCheckboxFn` and `ariaDropdownFn` functions
    2. the `onLabelCreate` and `updateSelectionLabel` functions

In `aria-dropdown.js` I had to mix jQuery and Vanilla JS somewhat, I
think the code is still understandable, otherwise the code would be much
more complex to read.

Thanks to fsologureng for the idea about "improving the 'delete icon'
with aria attributes".

If there is anything unclear or incorrect, feel free to ask and discuss,
or propose new PRs for it.
Add some review features that are notably missing from Gitlab CE but not
Gitea.

Also add Merge Queues which is not supported by Gitea but is quite an
important feature.
…ance (go-gitea#23570)

Before, the Vue `<SvgIcon>` always outputs DOM nodes like: 

```html
<span class="outer-class">
    <svg class="class-name-defined" ...></svg>
</span>
```

The `span` is redundant and I guess such layout and the inconsistent
`class/class-name` attributes would cause bugs sooner or later.

This PR makes the `<SvgIcon>` clear, and it's faster than before,
because it doesn't need to parse the whole SVG string.

Before: 

<details>

![image](https://user-images.githubusercontent.com/2114189/226156474-ce2c57cd-b869-486a-b75b-1eebdac8cdf7.png)

</details>

After:

![image](https://user-images.githubusercontent.com/2114189/226155774-108f49ed-7512-40c3-94a2-a6e8da18063d.png)

---------

Co-authored-by: silverwind <[email protected]>
Follow go-gitea#23037 
Fix [go-gitea#22598
comment](go-gitea#22958 (comment))

Workflows with `pull_request` trigger event can't be triggered by
`pull_request_sync` event. This PR adds the `canGithubEventMatch`
function to check if a Github event can match any Gitea event. If the
Github event matches a Gitea event, the related workflows should be
triggered.

---------

Co-authored-by: Lunny Xiao <[email protected]>
…-gitea#23574)

## TLDR

* Improve performance: lazy creating the tippy instances.
* Transparently support all "tooltip" elements, no need to call
`initTooltip` again and again.
* Fix a temporary tooltip re-entrance bug, which causes showing temp
content forever.
* Upgrade vue3-calendar-heatmap to 2.0.2 with lazy tippy init
(initHeatmap time decreases from 100ms to 50ms)

## Details

### The performance

Creating a lot of tippy tooltip instances is expensive. This PR doesn't
create all tippy tooltip instances, instead, it only adds "mouseover"
event listener to necessary elements, and then switches to the tippy
tooltip

### The general approach for all tooltips

Before, dynamically generated tooltips need to be called with
`initTooltip`.

After, use MutationObserver to:

* Attach the event listeners to newly created tooltip elements, work for
Vue (easier than before)
* Catch changed attributes and update the tooltip content (better than
before)

It does help a lot, eg:

https://github.com/go-gitea/gitea/blob/1a4efa0ee9a49d48549be7479a46be133b9bc260/web_src/js/components/PullRequestMergeForm.vue#L33-L36

### Temporary tooltip re-entrance bug

To reproduce, on try.gitea.io, click the "copy clone url" quickly, then
the tooltip will be "Copied!" forever.

After this PR, with the help of `attachTippyTooltip`, the tooltip
content could be reset to the default correctly.

### Other changes

* `data-tooltip-content` is preferred from now on, the old
`data-content` may cause conflicts with other modules.
* `data-placement` was only used for tooltip, so it's renamed to
`data-tooltip-placement`, and removed from `createTippy`.
Close go-gitea#23622 

As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.

Co-authored-by: Lunny Xiao <[email protected]>
…ministration, usage, development, contributing the 5 main parts (go-gitea#23629)

- **Installation**: includes how to install Gitea and related other
tools, also includes upgrade Gitea
- **Administration**: includes how to configure Gitea, customize Gitea
and manage Gitea instance out of Gitea admin UI
- **Usage**: includes how to use Gitea's functionalities. A sub
documentation is about packages, in future we could also include CI/CD
and others.
- **Development**: includes how to integrate with Gitea's API, how to
develop new features within Gitea
- **Contributing**: includes how to contribute code to Gitea
repositories.

After this is merged, I think we can have a sub-documentation of `Usage`
part named `Actions` to describe how to use Gitea actions

---------

Co-authored-by: John Olheiser <[email protected]>
That's incorrect code caused by Copy&Paste.

`show-modal` / `show-panel` are used by JS to show something, but these
links have `href`, they should navigate to new page.

Close go-gitea#23657
…er broken translations (go-gitea#23633)

It use old en-US locales as reference, fill the old other locales with
new locales.

----

## More broken translations

Many translations are still broken. The reason is: at the last time
restoring the ini to crowdin, many semicolon are treated as comments.

Two kinds of broken strings:

### Some translations can be re-translated

<details>

```
skipping options/locale/locale_si-LK.ini org teams.add_nonexistent_repo
skipping options/locale/locale_tr-TR.ini repo commits.search.tooltip
skipping options/locale/locale_es-ES.ini repo settings.trust_model.committer.desc
skipping options/locale/locale_es-ES.ini admin dashboard.new_version_hint
skipping options/locale/locale_pt-PT.ini org teams.add_nonexistent_repo
skipping options/locale/locale_hu-HU.ini install require_sign_in_view_popup
skipping options/locale/locale_hu-HU.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini org teams.add_nonexistent_repo
skipping options/locale/locale_de-DE.ini repo settings.protect_protected_file_patterns_desc
```

</details>

So this PR also does some small changes on them, to trigger the
re-translation.

### The `locale_el-GR.ini` contains many broken tranlsations

I guess we should reset them from crowdin side, then translators can
re-translate them.

----

Update: in latest main, the strings have been fixed.

## TODO

Update: the el-GR translators have done great job and fixes these broken
translations.


<details>

Merge this PR ASAP and upload `locale_el-GR.ini` to crowdin to remove
broken strings.


Out-dated, fixed in main.


![image](https://user-images.githubusercontent.com/2114189/226954531-36e14527-278a-41a1-8ddb-2b2b27bfc746.png)

</details>

---------

Co-authored-by: delvh <[email protected]>
…ea#23647)

Close go-gitea#23627 

Added margin left to the button when it is next to the svg, which has a
margin-right of `-0.5rem`

And here it might be better if `white-space: nowrap;` is added because
otherwise it might look like below on pull requests page on smaller
screen

<img width="945" alt="截屏2023-03-23 09 57 41"
src="https://user-images.githubusercontent.com/17645053/227079613-71c696ab-55ec-4641-acb9-622a8baebb31.png">

After:
<img width="936" alt="截屏2023-03-23 10 08 27"
src="https://user-images.githubusercontent.com/17645053/227080971-6bf2588e-40dd-4770-b0d1-45d7c63e0f48.png">

Pull Request on smaller screen
<img width="922" alt="截屏2023-03-23 10 25 16"
src="https://user-images.githubusercontent.com/17645053/227084144-0c2ed3e6-5c11-4252-bba2-b5f971b70f4a.png">
…ea#23650)

`HookEventType` of pull request review comments should be
`HookEventPullRequestReviewComment` but some event types are
`HookEventPullRequestComment` now.
Remove `[repository.editor] PREVIEWABLE_FILE_MODES` setting that seemed
like it was intended to support this but did not work. Instead, whenever
viewing a file shows a preview, also have a Preview tab in the file
editor.

Add new `/markup` web and API endpoints with `comment`, `gfm`,
`markdown` and new `file` mode that uses a file path to determine the
renderer.

Remove `/markdown` web endpoint but keep the API for backwards and
GitHub compatibility.

## ⚠️ BREAKING ⚠️

The `[repository.editor] PREVIEWABLE_FILE_MODES` setting was removed.
This setting served no practical purpose and was not working correctly.
Instead a preview tab is always shown in the file editor when supported.

---------

Co-authored-by: zeripath <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
…o-gitea#23653)

This PR is to fix the second problem mentioned in go-gitea#23625, along with the
long texts problem in `issue-item-bottom-row` of `issuelist.tmpl`

Main changes are:
1. Add `max-width` to the search dropdowns in issue list and make the
possible long texts inside to show ellipsis if texts are long
2. Adjust the conditions in
[issuelist.tmpl](https://github.com/go-gitea/gitea/blob/1d35fa0e784dffcadacb2322a3d7ac3ec2ff89b2/templates/shared/issuelist.tmpl#L146-L167)
to fix the problem as mentioned by the
[comment](go-gitea#23625 (comment))
3. Use `word-break: break-word;` in `issue-item-bottom-row` to break the
possible long texts.

After the PR
issuelist in repo (similar for pr list):
<img width="366" alt="截屏2023-03-23 17 42 40"
src="https://user-images.githubusercontent.com/17645053/227163953-93e9adbd-5785-4c16-b538-9db901787775.png">

dropdowns with long name (Here take reference from github to deal with
the long names cases: show ellipsis with no title, because all these
options are clickable, and it might not be necessary to add titles to
them ):

<img width="370" alt="截屏2023-03-23 17 43 50"
src="https://user-images.githubusercontent.com/17645053/227164215-df6fcaaa-9fee-4256-a57c-053fbcffafbb.png">

<img width="365" alt="截屏2023-03-23 17 43 56"
src="https://user-images.githubusercontent.com/17645053/227164227-9c99abcd-f410-4e07-b5b8-cbce764eedcd.png">

issue page (similar for pr page):
<img width="374" alt="截屏2023-03-23 17 45 37"
src="https://user-images.githubusercontent.com/17645053/227164668-654a8188-dac8-4bbf-a6e3-f3768a644a1b.png">

on PC:
<img width="1412" alt="截屏2023-03-23 17 47 20"
src="https://user-images.githubusercontent.com/17645053/227166694-e7bcc6e5-9667-4cef-9fbf-db85640a2c6c.png">

<img width="1433" alt="截屏2023-03-23 17 46 40"
src="https://user-images.githubusercontent.com/17645053/227165182-4e2a5d19-74bc-4c66-b73c-23cbca176ffe.png">
Before, in project edit page, the cancel button is not work.

https://user-images.githubusercontent.com/33891828/227182731-6478e29f-0e52-48c4-beb0-6a7d1dda6a1d.mov

1. The wrong classname `cancel` was added to the `<a>` tag. That
classname caused the default click event of `<a>` tag to be cancelled.
Because we have the following settings in the global. So I remove the
classname `cancel`.

https://github.com/go-gitea/gitea/blob/9be90a58754061171bbd5025d85d2b891364efd3/web_src/js/features/common-global.js#L325-L327

2. Another change is that page will redirect to the previous page.

https://user-images.githubusercontent.com/33891828/227187326-c653c6d6-9715-440f-a732-ba0a6f012c81.mov
Fixes go-gitea#23645
* Added `describedby` attribute to the reference element.
* Eliminated `aria-expanded` attribute to the reference element in order
to conform strictly with WCAG 2.1 rules.
Follow:
* go-gitea#23574
* Remove all ".tooltip[data-content=...]"

Major changes:

* Remove "tooltip" class, use "[data-tooltip-content=...]" instead of
".tooltip[data-content=...]"
* Remove legacy `data-position`, it's dead code since last Fomantic
Tooltip -> Tippy Tooltip refactoring
* Rename reaction attribute from `data-content` to
`data-reaction-content`
* Add comments for some `data-content`: `{{/* used by the form */}}`
* Remove empty "ui" class
* Use "text color" for SVG icons (a few)
Close go-gitea#20553

There were already a lot of functions powered by JavaScript in Gitea.

Without JavaScript, the Gitea Web UI almost doesn't work (only some
static links work ....)
# Conflicts:
#	templates/user/notification/notification_div.tmpl
#	web_src/less/_user.less
@jolheiser jolheiser merged this pull request into jolheiser:notification-table Mar 24, 2023
@wxiaoguang wxiaoguang deleted the notification-table branch March 24, 2023 15:51
jolheiser pushed a commit that referenced this pull request Jan 25, 2024
…28336)

This resolves a problem I encountered while updating gitea from 1.20.4
to 1.21. For some reason (correct or otherwise) there are some values in
`repository.size` that are NULL in my gitea database which cause this
migration to fail due to the NOT NULL constraints.

Log snippet (excuse the escape characters)
```
ESC[36mgitea                |ESC[0m 2023-12-04T03:52:28.573122395Z 2023/12/04 03:52:28 ...ations/migrations.go:641:Migrate() [I] Migration[263]: Add git_size and lfs_size columns to repository table
ESC[36mgitea                |ESC[0m 2023-12-04T03:52:28.608705544Z 2023/12/04 03:52:28 routers/common/db.go:36:InitDBEngine() [E] ORM engine initialization attempt #3/10 failed. Error: migrate: migration[263]: Add git_size and lfs_size columns to repository table failed: NOT NULL constraint failed: repository.git_size
```

I assume this should be reasonably safe since `repository.git_size` has
a default value of 0 but I don't know if that value being 0 in the odd
situation where `repository.size == NULL` has any problematic
consequences.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.